read project tsconfig.json when resolving compiler options - #1865

closes #1864

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you written unit tests?
• Have you written unit tests that cover the negative cases (i.e.: if bad data is submitted, does the library respond properly)?
• This PR is associated with an existing issue?

If this is a new feature submission:

• Has the issue had a maintainer respond to the issue and clarify that the feature is something that aligns with the goals and philosophy of the project?

Potential Problems With The Approach

validateCompilerOptions previously accepted config?: Record<string, unknown> and returned it cast as CompilerOptions. The new behaviour reads tsconfig.json from the current working directory upward, so callers that pass an explicit cwd argument can now control which tsconfig is discovered. Callers that pass neither config nor cwd will pick up whatever tsconfig.json TypeScript finds via ts.findConfigFile — this is the correct default, but if a project has an unusual tsconfig location the discovery path may differ from what was previously assumed (previously: nothing was read at all, so any change here is strictly an improvement).

The compilerOptions field in tsoa.json continues to work as before — values there are merged on top of the tsconfig-derived options, so explicit overrides take full precedence.

Test plan

New unit tests in tests/unit/swagger/validateCompilerOptions.spec.ts cover:

• tsconfig.json discovery — moduleResolution: bundler and customConditions: ["source"] are read from the fixture tsconfig and returned as the correct numeric TypeScript enum values.
• No tsconfig found — when cwd is / (filesystem root, which has no tsconfig), the returned options have no moduleResolution or customConditions set; the function does not throw.
• compilerOptions overrides — values in tsoa.json's compilerOptions block override the tsconfig-derived values; options not overridden (e.g. moduleResolution) are still present from the tsconfig.
• String-to-numeric enum conversion — passing { moduleResolution: "node16" } as an override produces ts.ModuleResolutionKind.Node16 (the numeric value), confirming that ts.convertCompilerOptionsFromJson is applied correctly.
• Cross-package plain interface — a controller importing Widget from a package resolved via paths in tsconfig correctly expands to its full property set (id, name, active). Without the fix this throws because paths is never read.
• Cross-package z.infer<> — a controller importing ZodWidget = z.infer<typeof ZodWidgetSchema> from the same cross-package source correctly expands to its full property set (id, label, enabled). Without the fix this throws for the same reason; even if it didn't, reading from a compiled .d.ts would collapse the type to {}.